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(54) IEEE 1394 Serial bus system using a mapping table for Identifying nodes having required 
capabilities to establish isochronous connections 



(57) In an IEEE- 1394 serial bus system, a control- 
ling node reads information from the configuration ROM 
of each of other nodes attached to the bus and estab- 
lishes in a mapping table a correspondence between 
the identifier of each node and the read information. The 
controlling node identifies particular nodes having 
required capabilrties according to the information stored 
in the mapping table and requests an isochronous 
resource n^nager to obtain information necessary for 
transmission of isochronous data. The obtained infor- 
mation is tiien set into plug control registers of the iden- 
tified nodes to establish a connection between the 
identified nodes. 
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Description 

BACKGROUND QF THE INVENTION 
Reld of the Invention 

[0001 ] The present invention relates generally to IEEE 
1394 serial bus systems and more specifically to an 
IEEE 1394 node capable of establishing connections for 
isochronous transmissjpns. " 

Description of the Related Art 

[0002] The IEEE-1394 Standanj for a High Perform- 
ance Serial Bus specifies a sequence of different proc- 
esses to be performed when the bus is initialized. One 
of such processes is the self identification process in 
which all nodes attached to the bus are Informed of the 
node identifiers of ail other nodes and the maximum 
speed of each bus segment that is attached between 
two nodes. However, if it is desired to transfer iso- 
chronous data such as video programs between two 
nodes of particular vendors, details of node information 
such as node capabilities and their node type are still 
required in order to identify the nodes supporting iso- 
chronous transmission before establishing a connec- 
tion. 

SUMMARY OF THE INVENTION 

[0003] It is therefore an object of the present invention 
to identify nodes having required node capabilities for 
isochronous transmission and establish a connection 
between the identified nodes. 

[0004] Accorcfing to the present inventioa there is pro- 
vided an IEEE-1394 serial bus system in which a plural- 
ity of nodes are attached to the serial bus. each of the 
nodes irK:luding a configuration ROM and identified by a 
node identifier. At least one of the nodes comprises a 
mapping table arKi control circuitry for reading informa- 
tion from the configuration ROM of each of other nodes 
and mapping the identifier of each other node to the 
read information in the maii^ing table, identifying a 
node having required node capabilities according to 
information scored in the mapping tattle, requesting an 
isochronous resource manager to obtain information 
necessary tor transmission of isochronous data, and 
setting the obtained information into the identified node 
to establish a connection which supports said transmis- 
sion. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0005] The present invention will be described in fur- 
ther detail with reference to the accompanying draw- 
ings, in which: 

Fig. 1 shows in block diagram form an IEEE 1394 



serial bus tree topology network according to the 
present invention: 

Fig. 2 shows details of a configuration ROM of each 
node of the tree topology network; 

5 Rg. 3 stows a table mapping process of the 
present invention at the level of transaction layer; 
Rgs. 4A to 4D show in flow diagram form the table 
mapping process of a controlling node; 
Figs. SA to 5D show the fomrats of packets used in 

10 the present inv^on; 

Rg. 6 shows in flow diagram form the operation of 
the connection establishment process of the con- 
trolling node; 

Rg. 7 shows information set in plug control regis- 
15 ters of audio/visual nodes; and 

Rg. 8 shows one sample of connections estab- 
lished among audioMsuat nodes of the IEEE 1394 
tree topology network. 

20 DETAILED DESCRIPTION 

[0006] Referring now to Rg. 1 . there is shown an IEEE 
1394 serial bus tree-topology network according to the 
present invention. The network is comprised of a plural - 

25 ity of IEEE 1394 devices, or nodes. One of the nodes is 
a controlling node 1 and the other nodes are controlled 
nodes, or target nodes 2A to 2G attached to the control- 
ling node by local buses 3 and 4 in a tree-like topology. 
Nodes 1 and 2 may be audio/visual devices or personal 

30 computers, or computer peripheral devices, all of which 
are designed to the IEEE Standard for a High Perform- 
ance Serial Bus (or IEEE Std 1394-1995) which sup- 
ports both asynchronous an6 isochronous 
transmissiorts, simultaneously. 

35 [0007] Controlling node 1 includes a controller 10, a 
transaction layer processor 1 1 . a link layer processor 12 
and a physical layer processor 1 3. all of which are con- 
' nected to a bus manager 14. By way of the processors 
11 to 13, the controller 10 transmits and receives sig- 

40 na!s to and from the local buses 3 and 4. Further asso- 
ciated with the controller 10 is a ntapping table 15 in 
which the controller 1 0 maps node identifiers to the cor- 
responding device information items obtained from the 
configuration ROM of target nodes in a manner as win 

45 be descn'bed in detail later. 

[0008] A memory 16 is provided within the bus man- 
ager 14 and a configuration ROM 17 is defined within 
the memory 16, Each of target nodes 2A to 2Q has its 
own configuration ROM. 

so [0009] AsshownindetaflinRg. 2,thememory 16of 
the controlling node as well as target nodes 2A to 2G is 
partitioned into a plurality of register spaces including 
the space for the configuration ROM 17. a space for 
GSR (control and status register) 18. and initial units 

55 space 19. Bus manager 14 controls the layers 11. 12 
and 13 according to the contents of the CSR memory 
space 18. After the mapping table 15 is completed, the 
controller 1 0 exchanges command messages with other 
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ncxJes using addresses specified in the C3R memory 
space 1 8. 

[001 0] Configuration ROM 1 7 is divided into a number 
of storage locations each with a 32-bit (quadlet) wide 
memory space. These quadlet storage locations are 
grouped into sections such as busjnfo.block. 
root_directory, unit_directories and a 
node_unjque_id Jeaves, and each section begins with a 
memory space in which the data length of the section 
and error check data areTindicated. 
[0011] AudioMsual nodes are provided with master 
plug registers and plug control registers designed to tiie 
I EC standard 61883 for digital interlace for consumer 
electronic audio/video equipment (reference number 
100C/46 - 50/CVD, project number 100C/61883- 
1-5/Ed.1). A maximum of thirty-two plug control regis- 
ters are provided in each of the target nodes 2. In each 
of these plug control registers are stored information 
relating to tfie presence/absence of broadcast cortnec- 
tion. the number of point-to-point connections, the iden- 
tification of an isochronous channel and the transfer rate 
and bandwidth of the isochronous channel. Manage- 
ment of the plug control registers is provided by the 
master plug registers. Plug control registers and master 
plug registers is defined within the initial units space 19 
as illustrated in Fig, 2. 

[0012] Controlling node 1 begins its operation with a 
bus initialization process by asserting a bus reset on 
local buses 3 and 4. Following the bus initialization, a 
tree identification process begins to identify the root 
node and the isochronous resource manager and the 
topology of all attached nodes, resulting in all ports of 
the nodes being designated as either child or parent 
ports. A child port connects to a node further away from 
the root while a parent port connects to a node closer 
to the root The tree identification process is then fol- 
lowed by a self identification process during which a 
physical identification is assigned to each node, neigh- 
boring nodes exchange their speed capabilities and ttie 
topology defined during tree identification. 
[0013] Following the self identification process, the 
controller 10 performs a nruipping process on the table 
15. The catsle mapping process of controller 10 begins 
at the transaction layer with a target node, 2A, for exam- 
ple, to establish corresporxlences in the mati^ing table 
15 between the identifier of the node 2A and a nurr^er 
of its unique device information items. As illustrated, the 
controller 1 0 at node 1 sends a transaction request to its 
transaction layer 1 1 to fonward a read request packet to 
the transaction laya* 1 1 A of node 2A. which replies with 
an acknowledgment packet and sertds a transaction 
indication to its configuration ROM 1 7A. This results in a 
desired data item t>eing reeuj out of the configuration 
ROM 1 7A and transmitted as a transaction re^x>nse to 
the ticuisaction layer 1 1 A. The configuration ROM data 
is placed in the data field of a read response packet and 
sent from the transaction layer 1 1 A to the transaction 
layer 1 1 , which retums an acknowledgment packet to 



node 2A and serxis a transaction incScation to the con- 
troller 10. The configuration ROM data of node 2A con- 
tained in tiie transaction indication is mapped in the 
mapping table IS to the identifier of node 2A. 

5 [0014] The following is a detailed description of the 
table mapping operation of controller 1 0 with the aide of 
the flowcharts of Rgs. 4A to 4D by using the standard- 
ized packets as shown in Rgs. 5A to 5D. 
[0015] The table mapping process begins with the 

10 reading of busJnto_l)lock section data from all target 
nodes- At step 101 . the controller 10 formulates a Read 
Data Quadlet (RDQ) unicast request packet (Rg, 5A) by 
setting SFFig (=1023) in the ten most significant bits of 
the destination 10 field to specify ail local buses and set- 

15 ting one of O^g to 3E^s ^ 'east significant bits and 
an address (FFFFF0000400i6} in the destination_offset 
field indicating the fmst quadlet data of busJnfb_block 
section. In this way. RDQ unicast packets can be indi- 
vidually addressed to a maximum of sixty-three target 

20 nodes. 

[0016] All nodes recognizing a receipt of the RDQ 
request packet Inow that they are being targeted and 
respond with a RDQ response packet which is ^own in 
Rg. 5B. More specifically, each target node reads the 

25 first quadlet (four bytes) data of bus Jnfo_t)lock section 
of its configuration ROM as specified by the 
destination_offs6t field of the received packet ard 
inserts this first quadlet data into the quadlet_data field 
of the RDQ response packet as well as the node ID of 

30 tiie target node into its sourceJD field. This first quadlet 
data includes the data length of the busJnfb_block sec- 
tion and ORG information (see Rg. 2). 
[0017] In response to receipt of tfie RDQ response 
packet from each target node (step 103). tiie controller 

3$ 10 proceeds to step 104 to save the source address 
contained in its sourceJD field and reads the length 
data of busJnf6_block section from ttie quadlet data 
field. 

[0018] At step 105. the corrtrolier 10 checks to see if 
^ RDQ response packets are received from ail target 
nodes. If not flow retums to step 1 01 to r^jeat the proc- 
ess until RDQ response packets are received from all 
target nodes. : 

[001 9] When the decision at st^ 1 05 becomes affirm- 
45 ative, flow proceeds to step 106 to add one quadlet to 
the initial offset data to produce a summed address 
value FFFFF0000404i5 which indicates the second 
address location of the busjnfojblock section and sul>- 
tract one quadlet from tiie length data saved at step 
so 104. 

[0020] At step 107, the controller 10 formulates a uni- 
cast Read Data Block (ROB) request packet (see Rg. 
5C) for a target node by setting the saved identifi©- of 
the node in the destination ID fiekJ of the packet the 
55 summed address value in the destination_offset field 
and the subtracted length data in the datajength field, 
the packet toeing fonrt/arded onto all local buses (step 
108) so that only one node specified by the destination 
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ID field knows that It being targeted. 
[0021 ] tn response to the ROB request packet the tar- 
get node repfies wrth a RDB respor^se packet (Rg. 50) 
by setting its data field with busJnfo_block section data 
that begins with the second address location specified 
by the request packet. 

[0022] Upon receipt of the ROB response packet from 
a target node (step 109), the controller 10 proceeds to 
step 110 to establish a correspondence in the niapping 
table 15 between the target node identifier and the 
bus_infb_block section data contained in the response 
packet 

[0023] At step 1 11, the controller 10 checks to see if 
RDB response packets are received from all target 
nodes. If not, flow returns to step 106 to repeat the proc- 
ess until ROB response packets are received from all 
target nodes. 

[0024] f=bllowing the affirmative decision at st^ 111. 
flow proceeds to step 201 (Rg. 4B) to start reading 
root_directory section data from the target nodes in a 
manner similar to the routine of Fig. 4A by formulating a 
unicast RDQ request packet In this untcast request 
packet all-bus address SFFfg is set in the ten most sig- 
nificarU bits of the destination ID field and an individual 
address is set in the six least significant bits simitar to 
step 1 01 and the first address (FFFFF000041 4^ g) of the 
root_directory section is set in the destination_offset 
field. 

[0025] The ROQ request packet is fbnwarded to ail 
local buses (step 202) so that all nodes know that they 
are being targeted and reply with RDQ response pack- 
ets each containing the data length of the root_directory 
section in its quadlet data field. 
[0026] Upon receipt of the RDQ response packet from 
each target node (step 203). the controller 10 proceeds 
to step 204 to save the source identifier and the length 
data of the rootjdirectory section. 
[0027] At step 205. the controller 10 checks to see if 
RDQ response packets are received from all target 
nodes. If not, the flow returns to step 201 to repeat the 
process until RDQ response packets are received from 
all target nodes. 

[0028] When the decision at step 205 thecomas afftrm- 
ative. flow proceeds to step 206 to add one quadlet to 
the initial offset data to produce a summed address indi- 
cating the second address location of the root.cGrectory 
section and sut>tract one quadlet from the length data 
saved at step 204. 

[0029] At step 207, the controller 1 0 formulates a ura- 
cast RDB request packet for a target node t>y setting the 
saved identifier of the node in the destination (0 field of 
the packet the summed address value in the 
destination^ offset field and the subtracted length data 
in the data Jength field. The packet is forwarded onto all 
local buses (step 208) so that only one node specified 
by the destination 10 field knows that it is being tar- 
geted. 

[0030] In response to the RD B request packet the tar- 



get node replies with a RDB response packet corrtaining 
in its data field rootjdirectory section data ttiat begins 
with the secorxl address location specified by the 
request packet 

5 [0031 ] Upon receipt of the ROB response packet from 
a target node (step 209). the controller 10 proceeds to 
step 210 to estat^Iish a correspondence in the mapping 
table 15 between the identifier of the target node and 
. the root_directory section data contained in the 

10 response packet 

[0032] At step 211. the controller saves the 
unit_directory offset data and node.uniquejd Jeaf off- 
set data contained tn the data field of the response 
packet, and proceeds to step 21 2 to check to see if RDB 

15 response packets are received from all target nodes. If 
not, flow returns to step 206 to repeat the process until 
ROB response packets are received from all target 
nodes. 

[0033] Following the affirmative decision at step 21 2. 

20 flow proceeds to step 301 (Rg. 4C) to start reading the 
unit.directory section data from each target node by for- 
mulating a unicast ROQ request packet In this unicast 
request packet the identifier of a node saved at step 211 
is set in tiie destination ID field arxJ the unit_directory 

25 offset data saved at step 211 is set in the 
destinationjoffset field. The untcast packet is forwarded 
onto the local txises at step 302, so that only one node 
knows tfiat it is being targeted. The target node replies 
with a ROQ respcxise packet containing the length data 

30 of the unit_directory secticwi. 

[0034] When the controlling node 1 receives the RDQ 
response packet (st^ 303), flow proceeds to step 304 
to save the node identifier and length data arxi pro- 
ceeds to step 305 to check to see if ROQ response 

35 packets are received from all target nodes. If not. flow 
returns to step 301 to repeat the process until ROQ 
response packets are received from all target nodes. 
[0035] When the decision at step 305 becomes affirm- 
ative, flow proceeds to step 306 to add one quadlet to 

40 the unit_directory offset data of a given node saved at 
step 304 to specify the second address location of 
tmit.directory section and subtract one quadlet from the 
length data saved at step 211. 
[0036] At step 307. tiie controller 10 fornuilates a ROB 

45 request packet for the given node by setting its saved 
fdentrfier in the destination 10 field, summed address in 
the destination_offset field and tiie sut^tracted lengtii 
data in tiie datajength field. At step 308. the ROB 
request packet is forwarded onto the local tmses. 

so [0037] In response to the ROB request packet the 
given target node replies with a ROB response packet 
containing in its data fiekj unitjdirectory section data, 
[0038] When the controller 10 receives tfie ROB 
response packet at step 309. H ixoceeds to step 310 to 

55 establish a correspondence in the mapping table 15 
between the identifier of the given node and the 
unitjdirectory section data contained in the packet At 
step 311. the controller 10 checks to see if ROB 
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response packets are received from all target nodes, tf 
not, steps 306 to 310 are repeated until RDB response 
packets are received from all nodes. 
[0039] Following the affirmative decision at step 311. 
flow proceeds to step 401 (Fig. 40) to start reading 
node_unique_ idjeaf section data from each target 
node by formulating a unicast RDQ request packet tn 
this unicast request packet the identifier of a node saved 
at step 211 is set in the destination 10 field and the 
node_unique_idJeaf offset data saved at step 211 is 
set in the destination_offset field- The unicast packet is 
forwarded onto tiie local txises at step 402. so that only 
one node knows that it is being targeted- The target 
node replies with a RDQ response packet containing 
the length data of the node_unique_idJeaf section. 
[0040] In response to receipt of the RDQ response 
packet (step 403), flow proceeds to step 404 to save the 
node identifier and length data and proceeds to step 
405 to check to see if RDQ response packets are 
received from all target nodes. If not flow returns to step 
401 to repeat the process until RDQ response packets 
are received from all target nodes, 
[0041 3 When the decision at step 405 becomes affirm- 
ative, flow proceeds to step 406 to add one quadlet to 
the node_unique_idJeaf offset data of a given node 
saved at step 404 to specify the second address loca- 
tion of node_unique_idJeaf section and sulstract one 
quadlet from the length data saved at step 21 1. 
[00421 At step 407. the controller 1 0 formulates a RDB 
request packet tor the given node by setting its saved 
identifier in the destination ID fieM, summed address in 
the destination_offset field and the subtracted length 
data in the datajength field. At step 408, the RDB 
request packet is forwarded onto the local buses. 
[0043] In response to tiie RDB request packet the 
given target node replies with a RDB re^sonse packet 
containing in its data field node_unique_idJeaf section 
data. 

[0044] When the controller 10 receives the RDB 
response packet at step 409, it proceeds to step 410 to 
establish a correspondence in the mapping table 15 
between the identifier of the given node and the 
unit_directory section data contained in the packet At 
step 411. the controller 10 checks to see if ROB 
response packets are received from all target nodes, tf 
not steps 406 to 410 are repeated until RDB response 
packets are received from all nodes, whereupon all rou- 
tines of the table mapping process is terminated. 
[0045] With the mapping table 1 5 being conpleted as 
shown in Fig. 1, the controlling node 1 starts a process 
for establishing a comection between two audio/visual 
nodes. 

[0046] As shown in Fig. 6, the connection establish- 
ment process begins with step 61 in which the controller 
10 reads information from all entries of the mapping 
table 15 and identifies nodes having isochronous trans- 
mission capabilities. At step 62. the controller 10 sends 
an asynchronous lock packet to the isochronous 



resource manager to request the use of a bandwidth. If 
the request is granted, the isochronous resource man- 
ager returns a response packet indicating a channel 
nuoiber and a bar>dwidth. The controller 10 sets ttie 

5 requested information and other necessary information 
into the input arxJ output plug control registers of the 
identified nodes as shown in Fig. 7 according to the 
IEC-61883 standard. At step 63. the controller 10 com- 
mands the output plug control register to estatalish a 

10 connection to the input plug control register according to 
the set information. In this way, an isochronous channel 
is estatsiished between audioAnsual nodes for transmis- 
sion of isochronous data. 

[0047] Fig. 8 shows one example of connections 
IS established among audic/visual nodes of the present 
invention. It is seen that a plurality of connectioris are 
estatslished on a single isochronous channel. One 
point-to-point connection 81 is established between the 
output plug control register 91 of node 71 and the input 
20 plug control register 95 of node 75. two point-to-point 
connections ^ are estat^lished between the output 
PGR 91 and tiie input PGR 93 of node 73, and three 
point-to-point connections 83 are established between 
the output PGR 91 and tiie input PGR 92 of node 72. 
25 Additionally, a broadcast-out connection 84 is estab- 
lished between the output PGR 91 and the broadcast 
channel number of the isochronous channel and a 
broadcast-in connection 85 is established between the 
input PGR 95 and the broadcast channel number. 
30 These broadcast connections are established inde- 
pendentiy of the operating states of the transmit and 
receive nodes. The plug control registers of tiie broad- 
cast connections can be rewritten from any other nodes 
of ttie network, so that an established broadcast con- 
35 nection can be cleared and the ownership of the con- 
nection be transferred to another node. 
[0048] With a connection being established between 
two audioA/isual nodes, startfetop. pause and slow- 
motion cbntmands (AV/G commands) are used to con- 
40 trot video program transmissions according to the func- 
tion control protocol (FCP) of the lEC-61883 standard 
(step 64). At the end of the isochronous transmission 
(step 65), the input arKl output plug control registers of 
the audioAnsi^l nodes are reset to release the connec- 
ts tion (step 66)- 

Clafms 

1. A node attached to an IEEE- 1394 serial bus for 
so controlling devices attached to said bus, each of 
said devices incJuding a configuration ROM and 
identified by an identifier, said node comprising: 

a mapping catste; and 
55 control circuitry for reading information from the 

configuration ROM of each of said devices and 
mapping the identifier of tiie device to the read 
information in said mapping tattle, identifying a 
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device having required capabilities according 
to information stored in said mapping taWe. 
requesting an isochronous resource manager 
to obtain information necessary for transmis- 
sion of isochronous data, stnti settirig the 5 
obtained information into said identified device 
to establish a connection which supports said 
transmission. 

2. An IEEE-1 394 serial bus system in which a plurality 10 
of nodes are attached to the serial bus. each of said 
nodes including a configuration ROM and identified 

by a node identifier, at least one of said nodes com- 
prising: 

rs 

a mapping table; and 

control circuitry for reading information from the 
configuration ROM of each of other rKxIes and 
mapping the identifier of each other node to the 
read information in said mapping table, identi- 20 
fying a node having required node capabilities 
according to information stored in said map- 
ping table, requesting an isochronous resource 
manager to obtain information necessary for 
transmission of isochronous data, and setting 25 
the oiMained information into said identified 
node to establish a connection which supports 
said transmission. 

3. A method for establisliing a connection between 30 
ones of a plurality nodes attached to an IEEE-1 394 
serial bus. each of said nodes including a configu- 
ration ROM and identified by a node identifier, com- 
prising the steps of. 

3S 

a) reading information from the configuration 
ROM of each of said nodes and mapping the 
identifier of the node to the read information in 
a mapping table; 

b) identifying a node having required node 4o 
capabilities according to information stored in 
said mapping tatsfe; 

c) requesting an isochronous resource man- 
ager to obtain information necessary for trans- 
mission of isochronous data; and 45 

d) establishing a connection to said identified 
node acconding to the obtained information. 

4. The method of claim 3, wherein the step (a) com- 
prises the steps of: so 

reading a data quadlet from the configuration 
ROM of each node: arxi 
reading a data block from a location of the con- 
figuration ROM of the node which is specified 55 
by said data quadlet and mapping the data 
t>locK to the node kjentifier of the node in said 
mapping table. 



5. The method of claim 3, wherein the step (a) com- 
prises the steps of: 

transmitting a read data quadlet (ROO) unicast 
request packet to the serial bus indicating a 
storage location of a data quadlet and receiving 
a (RDQ) response packet from each of said 
nodes indicating the data length of a data block 
following said data quadlet; and 
transmitting a read data block (ROB) unicast 
request packet to the serial bus indicating said 
data ler^gth and a storage location of said data 
block and receiving a RDB response packet 
from each node so that said data block is 
obtained from the configuration ROM of the 
node and ms^ing the obtained data block to 
the node identifier of the node in said mapping 
table. 

6. The method of claim 3. wherein said identified node 
includes a plug control register, wherein step (b) 
oomprises: 

reading data from the mapping cable to identify 
ones of said nodes having required node capa- 
bilities; 

requesting an isochrcwious resource manager 
to obtain information necessary for transmis- 
sion of isochronous data; 
setting the obtained information into the plug 
control register of said Wentified node; and 
establishing a connection according to the 
information set in said plug control register. 
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